Amis lecteurs, bonjour !
Histoire de changer un peu de sujet, tout en restant dans le domaine du jeu vidéo et de sa création, je vous propose une nouvelle catégorie d'articles. Certains d'entre vous connaissent probablement les détails des métiers du jeu vidéo, et je ne suis pas un expert en la matière, mais je peux apporter quelques éclaircissements ( et désillusions ^^ ) pour les autres !
Pour commencer, un métier sujet à gros stéréotypes : Le testeur de jeux. Pas ceux qui écrivent des tests sur les jeux ( ce sont plutôt des journalistes / critiques spécialisés ). En théorie, participer à un béta test fait de vous un testeur de jeu ( non professionnel ). Mais sur les gros projets de jeux vidéos, on a besoin d'une équipe de testeurs pour tester les fonctionnalités du jeu. Oui, on joue à un jeu vidéo, mais non, on n'est pas là pour le plaisir de jouer.
En premier lieu, le testeur a accès à une version du programme encore en développement. Il y a des bugs, des éléments graphiques sans textures ( monochromes ), Le programme peut même planter dans plusieurs cas différents... Bref on ne joue pas forcément sur une version stable, aboutie graphiquement et fonctionnellement.
Ensuite, le travail principal du testeur consiste à explorer chaque recoin, à essayer n'importe quelle possibilité offerte par le jeu ( même les plus étranges et incongrues ). Lorsque le testeur détecte le moindre problème, il doit dans la mesure du possible :
-Déterminer l'origine du bug : Est-ce un oubli d'un graphiste, une boulette de programmeur ?
-Selon le cas : Décrire le contexte, comment le reproduire...
Ensuite il rédige un rapport de bug avec des outils spécifiques, comme par exemple Mantis Bug Tracker ( https://www.mantisbt.org/ ). Quand un testeur rapporte un bug, il se doit de donner le maximum d'informations pour que les développeurs puissent rapidement identifier la cause du problème.
Allez dire à un programmeur : "Le jeu plante". Le programmeur va vous demander : "A Quel moment ? En jeu ? Dans le menu ? En faisant une action en particulier ? Quel est le message d'erreur ? etc...". Sans ces informations, le programmeur sait seulement que le jeu peut planter. Il n'a aucune information supplémentaire sur le bug, et doit donc chercher par lui même ( en combinant ses compétences de programmeur et de testeur ) comment reproduire le bug, sa cause, puis comment le résoudre. Sur un petit projet, on peut s'en sortir. Mais imaginez un projet avec 50 programmeurs, de 200 000 à 1 000 000 de lignes de code pour faire fonctionner le jeu... Si les bugs sont rapportés avec un minimum d'informations, il est quasiment impossible d'en identifier la cause rapidement. C'est donc aux testeurs de fournir un rapport de bug suffisement détaillé pour gagner un maximum de temps au programmeur. L'idéal étant qu'il puisse reproduire directement le problème pour tester ce que fait le code ligne par ligne ( débug ) et trouver une solution au problème.
Pour aider les développeurs, les testeurs peuvent ajouter aux rapports de bug des screenshots, les rapports d'erreurs rencontrés, mais aussi les fichiers log produits par le jeu. Les fichiers log contiennent des informations sur le déroulement du programme du jeu. les programmeurs écrivent des lignes de texte dans les fichiers log pour avoir des informations sur ce qui s'est passé pendant l'execution du programme. Imaginez que l'on cherche une image dans un dossier et qu'on ne la trouve pas, alors qu'on en a besoin. On le note dans le fichier log. Ca permet de savoir qu'il manque une image sur l'installation du testeur ( et peut être à tout le monde ). Ces fichiers contiennent des informations très importantes pour analyser et corriger les erreurs. Il peut même arriver que le jeu tourne sans problèmes, mais que les fichiers log contiennent des informations cruciales sur un bug important ( fuites mémoires, objets graphiques non trouvés dans les dossiers, etc... ).
La base de bugs est analysée et traitée par une ou plusieurs personnes ( souvent les lead-prog et Art ), pour trier les rapports, détecter les doublons, affecter des priorités aux bugs, ajouter des notes, puis les assigner aux programmeurs ou aux graphistes...
Voila en quoi consiste principalement le travail d'un testeur de jeux. Une bonne connaissance en langue(s) est requise ( en général l'anglais est souvent au programme ).
Je vais vous donner quelques exemples que nous avons pu découvrir en développant notre projet. En tant que programmeurs, on doit forcément vérifier que ce que l'on code fonctionne. Ca parrait logique. Donc lorsqu'on code une fonctionnalité, on s'assure qu'elle fonctionne correctement ( dans la mesure du possible ). On a l'habitude des bugs, et une bonne partie est corrigée avant que le programme ne remonte aux testeurs ( c'est d'ailleurs les progs qui voient les bugs les plus étranges ). Mais il arrive que l'on ne pense pas à essayer certaines combinaisons qui se révèlent... désastreuses =)
On a par exemple découvert pas mal de crashes ( programme qui se ferme avec un message d'erreur ) lorsque l'on présentait notre version et que notre enseignant testait le jeu. D'une façon similaire ( quand quelqu'un d'autre a testé le jeu ), on a découvert un bug qui permettait de lancer une partie avec un nombre d'IA illimité ( Imaginez les screens dans l'article précédent, mais avec 50 lézards dans la map ). D'ou l'importance du test d'un jeu !
En jouant à GTA San andreas sur PS2 récement, j'ai eu l'occasion de voir 2 ou 3 bugs assez comiques : Un policier qui suit la route bien tranquillement, et qui sans explication valable vire à droite brutalement et se mange un mur à bonne vitesse pour finir éjecté de sa moto ( Surtout un problème de l'IA ). Ou encore en sortant d'un batiment ou d'une mission ( vu deux fois ) certains personnages affichés à moitié dans le sol... Je me suis dit qu'ils auraient pu prévoir 1 ou 2 semaines de débug supplémentaire ^^
J'éspère que l'article vous a plu.
Si vous avez des questions, des remarques, des choses à ajouter, ou si vous voulez partager quelques bugs que vous avez rencontré, n'hésitez pas !
Coco